I'm still kind of meh on these deprecations personally, but we should probably finish what was started.

With that said, I'm strongly opposed to applying #[doc(hidden)] to deprecated items. I'm not sure why you're doing that here. It seems like an obviously bad user experience that only serves to gaslight users. Imagine reading old code, wondering what a function does and then going to look it up in the docs only to find that... it isn't there?

Once the #[doc(hidden)] attributes are removed, I'd be happy to kick off an FCP.

The job x86_64-gnu-tools failed! Check out the build log: (web) (plain enhanced) (plain)

[RUSTC-TIMING] build_script_build test:false 0.101
[RUSTC-TIMING] cc test:false 0.663
   Compiling compiler_builtins v0.1.160 (/checkout/library/compiler-builtins/compiler-builtins)
[RUSTC-TIMING] build_script_build test:false 0.237
error: use of deprecated constant `core::f64::EPSILON`: replaced by the `EPSILON` associated constant on `f64`
  --> library/compiler-builtins/compiler-builtins/src/math/../../../libm/src/math/rem_pio2f.rs:21:31
   |
21 | const TOINT: f64 = 1.5 / f64::EPSILON;
   |                               ^^^^^^^
   |
   = note: `-D deprecated` implied by `-D warnings`
   = help: to override `-D warnings` add `#[allow(deprecated)]`

I've removed the #[doc(hidden] attributes.
Regarding why I added them, it is mostly the feeling that having twelve deprecated modules right on the front page of the std documentation is not a good user experience either.
Also, people who would search the docs for core::u8::MAX would still get u8::MAX as their first search result to find out what the constant means.

Regarding why I added them, it is mostly the feeling that having twelve deprecated modules right on the front page of the std documentation is not a good user experience either.

Perhaps! But the solution is definitely not to completely hide them.

Also, people who would search the docs for core::u8::MAX would still get u8::MAX as their first search result to find out what the constant means.

Sure, same thing applies here. I don't know anything about how rustdoc's search result ranking works, but it seems reasonable that it could take deprecation status into account.

@rfcbot merge

Team member @BurntSushi has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @the8472

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

🔔 This is now entering its final comment period, as per the review above. 🔔

marking the std::u8 etc. modules as fully deprecated and as #[doc(hidden)].

It seems the doc(hidden) part got removed; please also update the PR description since it will permanently become part pf the git history.

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

I've removed the #[doc(hidden] attributes. Regarding why I added them, it is mostly the feeling that having twelve deprecated modules right on the front page of the std documentation is not a good user experience either.

This might be a general area of improvement of Rust Docs. Move older deprecated modules/structs/etc into a hidden state (if anything was deprecated an automatic mention at top to 'optionally include them'), search would not be affected of course.

When I say 'older' I literally mean code deprecated eg 12 months ago based on publishing date.